Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove parentRendered argument #73877

Merged
merged 1 commit into from
Dec 17, 2024

Conversation

acdlite
Copy link
Contributor

@acdlite acdlite commented Dec 13, 2024

It doesn't look like this argument is logically needed. No callers pass it as an option except for the recursive call, and the recursive call will never set it to true because of the renderComponentsOnThisLevel branch that happens earlier in the function.

I'm guessing it was needed at one point but then the logic changed.

@ijjk ijjk added created-by: Next.js team PRs by the Next.js team. type: next labels Dec 13, 2024
@ijjk
Copy link
Member

ijjk commented Dec 13, 2024

Stats from current PR

Default Build (Increase detected ⚠️)
General
vercel/next.js canary acdlite/next.js remove-parentrendered-argument Change
buildDuration 22.2s 19.8s N/A
buildDurationCached 18.7s 15.9s N/A
nodeModulesSize 410 MB 410 MB N/A
nextStartRea..uration (ms) 531ms 526ms N/A
Client Bundles (main, webpack)
vercel/next.js canary acdlite/next.js remove-parentrendered-argument Change
1187-HASH.js gzip 51.1 kB 51.1 kB N/A
8276.HASH.js gzip 169 B 168 B N/A
8377-HASH.js gzip 5.36 kB 5.36 kB N/A
bccd1874-HASH.js gzip 53 kB 53 kB N/A
framework-HASH.js gzip 57.5 kB 57.5 kB N/A
main-app-HASH.js gzip 232 B 235 B N/A
main-HASH.js gzip 34.1 kB 34 kB N/A
webpack-HASH.js gzip 1.71 kB 1.71 kB N/A
Overall change 0 B 0 B
Legacy Client Bundles (polyfills)
vercel/next.js canary acdlite/next.js remove-parentrendered-argument Change
polyfills-HASH.js gzip 39.4 kB 39.4 kB
Overall change 39.4 kB 39.4 kB
Client Pages
vercel/next.js canary acdlite/next.js remove-parentrendered-argument Change
_app-HASH.js gzip 193 B 193 B
_error-HASH.js gzip 193 B 193 B
amp-HASH.js gzip 512 B 510 B N/A
css-HASH.js gzip 343 B 342 B N/A
dynamic-HASH.js gzip 1.84 kB 1.84 kB
edge-ssr-HASH.js gzip 265 B 265 B
head-HASH.js gzip 363 B 362 B N/A
hooks-HASH.js gzip 393 B 392 B N/A
image-HASH.js gzip 4.49 kB 4.49 kB N/A
index-HASH.js gzip 268 B 268 B
link-HASH.js gzip 2.35 kB 2.34 kB N/A
routerDirect..HASH.js gzip 328 B 328 B
script-HASH.js gzip 397 B 397 B
withRouter-HASH.js gzip 323 B 326 B N/A
1afbb74e6ecf..834.css gzip 106 B 106 B
Overall change 3.59 kB 3.59 kB
Client Build Manifests
vercel/next.js canary acdlite/next.js remove-parentrendered-argument Change
_buildManifest.js gzip 749 B 746 B N/A
Overall change 0 B 0 B
Rendered Page Sizes
vercel/next.js canary acdlite/next.js remove-parentrendered-argument Change
index.html gzip 524 B 523 B N/A
link.html gzip 539 B 537 B N/A
withRouter.html gzip 520 B 519 B N/A
Overall change 0 B 0 B
Edge SSR bundle Size
vercel/next.js canary acdlite/next.js remove-parentrendered-argument Change
edge-ssr.js gzip 128 kB 128 kB N/A
page.js gzip 204 kB 204 kB N/A
Overall change 0 B 0 B
Middleware size
vercel/next.js canary acdlite/next.js remove-parentrendered-argument Change
middleware-b..fest.js gzip 671 B 668 B N/A
middleware-r..fest.js gzip 155 B 156 B N/A
middleware.js gzip 31.2 kB 31.2 kB N/A
edge-runtime..pack.js gzip 844 B 844 B
Overall change 844 B 844 B
Next Runtimes
vercel/next.js canary acdlite/next.js remove-parentrendered-argument Change
523-experime...dev.js gzip 322 B 322 B
523.runtime.dev.js gzip 314 B 314 B
app-page-exp...dev.js gzip 323 kB 323 kB N/A
app-page-exp..prod.js gzip 127 kB 127 kB N/A
app-page-tur..prod.js gzip 140 kB 140 kB N/A
app-page-tur..prod.js gzip 135 kB 135 kB N/A
app-page.run...dev.js gzip 314 kB 314 kB N/A
app-page.run..prod.js gzip 123 kB 123 kB N/A
app-route-ex...dev.js gzip 37.4 kB 37.4 kB
app-route-ex..prod.js gzip 25.5 kB 25.5 kB
app-route-tu..prod.js gzip 25.5 kB 25.5 kB
app-route-tu..prod.js gzip 25.3 kB 25.3 kB
app-route.ru...dev.js gzip 39 kB 39 kB
app-route.ru..prod.js gzip 25.3 kB 25.3 kB
pages-api-tu..prod.js gzip 9.69 kB 9.69 kB
pages-api.ru...dev.js gzip 11.6 kB 11.6 kB
pages-api.ru..prod.js gzip 9.68 kB 9.68 kB
pages-turbo...prod.js gzip 21.7 kB 21.7 kB
pages.runtim...dev.js gzip 27.4 kB 27.4 kB
pages.runtim..prod.js gzip 21.7 kB 21.7 kB
server.runti..prod.js gzip 916 kB 916 kB
Overall change 1.2 MB 1.2 MB
build cache Overall increase ⚠️
vercel/next.js canary acdlite/next.js remove-parentrendered-argument Change
0.pack gzip 2.06 MB 2.06 MB ⚠️ +679 B
index.pack gzip 72.7 kB 72.1 kB N/A
Overall change 2.06 MB 2.06 MB ⚠️ +679 B
Diff details
Diff for main-HASH.js

Diff too large to display

Diff for app-page-exp..ntime.dev.js

Diff too large to display

Diff for app-page-exp..time.prod.js

Diff too large to display

Diff for app-page-tur..time.prod.js

Diff too large to display

Diff for app-page-tur..time.prod.js

Diff too large to display

Diff for app-page.runtime.dev.js

Diff too large to display

Diff for app-page.runtime.prod.js

Diff too large to display

Commit: 4bbbd7e

@ijjk
Copy link
Member

ijjk commented Dec 13, 2024

Tests Passed

It doesn't look like this argument is logically needed. No callers pass
it as an option except for the recursive call, and the recursive call
will never set it to `true` because of the `renderComponentsOnThisLevel`
branch that happens earlier in the function.

I'm guessing it was needed at one point but then the logic changed.
@acdlite acdlite force-pushed the remove-parentrendered-argument branch from a4c1e0c to 4bbbd7e Compare December 17, 2024 17:36
@acdlite acdlite enabled auto-merge (squash) December 17, 2024 17:52
@acdlite acdlite merged commit 5b60c13 into vercel:canary Dec 17, 2024
103 checks passed
acdlite added a commit that referenced this pull request Dec 18, 2024
Based on:

- #73945
- #73853
- #73667
- #73877

---

This implements support for the Segment Cache in projects/pages where
PPR is not enabled.

I originally thought the Segment Cache would be tied to the roll out of
PPR, because to take full advantage of per-segment caching, you need PPR
to generate static shells for each segment. However, as I was
investigating how to support the incremental PPR opt-in API, where some
pages support PPR and others don't — perhaps just by falling back to the
old cache implementation — I realized that there are benefits to
per-segment caching even if the requests themselves are not per-segment.

For example, when performing a non-PPR-style prefetch, the server diffs
the prefetched page against a description of the base page sent by the
client. In the old caching implementation, the base tree represented
whatever the current page was at the time of the prefetch. In the
Segment Cache implementation, we improve on this by telling the server
to exclude any shared layouts that are already in the client cache.

This ended up requiring more code than I would have preferred, because
dynamic server responses and per-segment server responses have
differentformats and constraints. However, I realized I was going to
have to implement most of this regardless in order to support `<Link
prefetch={true}>`, which performs a full dynamic request.

Once more of the pieces are settled, we can simplify the implementation
by unifying/redesigning some of the data structures, especially
FlightRouterState, which has become overloaded with many different
concerns. But we need to land some of our experiments first — one reason
there's more code than you might expect is because of all the different
combinations of features/experiments we need to support simultaneously.

While it's likely that PPR will be enabled by default sometime within
the next few release cycles, supporting non-PPR projects means we have a
pathway to rolling out additional prefetching improvements (like
prioritization and cancellation) independently of the PPR release.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants